Clinivault Trigger icon

Clinivault Trigger

Starts the workflow when a webhook is called

Clinivault Trigger

AI-generated

Overview

This node implements a webhook trigger designed to start workflows when an HTTP request is received. It supports listening on customizable paths and HTTP methods, including multiple methods simultaneously. The node is particularly useful for integrating external systems or services that send data via webhooks, enabling automated processing of incoming requests.

Common scenarios include:

  • Receiving notifications or data updates from third-party APIs.
  • Triggering workflows based on form submissions or events from other applications.
  • Handling file uploads or binary data sent via HTTP requests.
  • Processing healthcare-related resource data (given the extensive list of supported resource types).

Practical example:

  • A healthcare application sends patient data as JSON to the webhook URL; this node triggers a workflow that processes and stores the data.
  • An external system posts files to the webhook; the node captures the binary data and initiates further processing.

Properties

Name Meaning
Allow Multiple HTTP Methods Whether the webhook listens for multiple HTTP methods at once.
HTTP Method The single HTTP method to listen to if multiple methods are not allowed. Options: DELETE, GET, HEAD, PATCH, POST, PUT.
HTTP Methods The HTTP methods to listen to if multiple methods are allowed. Options: DELETE, GET, HEAD, PATCH, POST, PUT.
Path The URL path to listen on. Supports dynamic segments using : notation, e.g., your-path/:id.
Resource Type The type of resource expected in the webhook payload. Includes many predefined healthcare-related resource types (e.g., Patient, Observation) and a custom option.
Custom Resource Type If "Custom" resource type is selected, specify the custom resource type string here.
Tenant ID Optional tenant identifier to include in the request body.
Authentication Method of authenticating incoming webhook requests. Options: Basic Auth, Header Auth, JWT Auth, None.
Respond When and how to respond to the webhook request. Options: Immediately upon receiving, When last node finishes execution, Using a separate 'Respond to Webhook' node, Streaming response (real-time data).
Response Code HTTP status code to return in the webhook response (when responding immediately or when last node finishes). Typical codes like 200, 201, 204, 400, 401, 403, 404, or custom code.
Response Data What data to return in the response when responding after last node finishes. Options: All entries, First entry JSON, First entry binary, No response body.
Property Name Name of the property to return data from instead of the whole JSON object (used with some response modes).
Response Binary Property Name Name of the binary property to return when returning binary data.
Options Additional options such as:
- Binary File: whether the webhook receives binary data (for PATCH, PUT, POST).
- Field Name for Binary Data: output field name for binary data.
- Ignore Bots: ignore bot requests.
- IP Whitelist: comma-separated allowed IPs.
- No Response Body: whether to send any body in the response.
- Response Headers: custom headers to add to the webhook response.

Output

The node outputs a single item containing:

  • json: An object with the following structure:

    • headers: HTTP headers from the incoming request.
    • params: URL parameters extracted from the path.
    • query: Query string parameters.
    • body: The parsed request body merged with the optional tenant ID.
    • rawBody: Raw request body as a UTF-8 string if requested.
    • method: HTTP method used.
    • resourceType: The resolved resource type string.
  • binary (optional): Contains any binary files uploaded via the webhook. Each binary file is stored under a property named according to configuration, holding the file data and metadata.

This structure allows downstream nodes to access all relevant request data, including headers, parameters, body content, and any uploaded files.

Dependencies

  • Requires an HTTP server environment capable of receiving webhook calls.
  • Supports authentication methods requiring credentials or tokens configured in n8n.
  • Uses temporary file storage for handling binary uploads.
  • Depends on standard Node.js modules (fs, stream/promises) and n8n workflow utilities.
  • No external API dependencies beyond the webhook HTTP interface.

Troubleshooting

  • Missing Resource Type: The node throws an error if no resource type is specified. Ensure the "Resource Type" or "Custom Resource Type" property is set.
  • Authentication Failures: If authentication is enabled but credentials are incorrect or missing, webhook requests will be rejected. Verify authentication settings and credentials.
  • Binary Data Handling: Large file uploads may fail if temporary storage is insufficient or permissions are lacking. Check disk space and file system permissions.
  • IP Whitelist Blocking: If IP whitelist is configured, requests from non-whitelisted IPs will be ignored. Confirm the client IP is included in the whitelist.
  • Ignoring Bots: Enabling "Ignore Bots" may cause legitimate requests from certain user agents to be dropped. Adjust this setting if needed.
  • Response Mode Misconfiguration: Selecting "Using 'Respond to Webhook' Node" requires adding a corresponding node to handle responses; otherwise, the webhook may hang or timeout.
  • Raw Body Option: Enabling raw body reading can affect performance and memory usage; use only if necessary.

Links and References

Discussion